Performing error handling in complex workflows is not trivial. Usually the workflow designer expresses all of the potential errors and describes the counter-actions and the new steps the workflow should progress in order to recover the error or move to an acceptable final state. Transaction “rollback” is generally understood in the art as an operation which returns a system (e.g., often a database) to some previous state. Rollbacks are important for system integrity, because they can restore a system/database to a clean copy even after erroneous operations are performed. For example, if a database server crashes, rolling back any transaction which was active at the time of the crash can restore the database to a consistent state. One example and well-known rollback technique in traditional databases is known as “ACID” (Atomicity, Consistency, Isolation, Durability), which is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc.
As workflows become increasingly more complex, however, the number of combinations that need to be accounted for is also higher (e.g., path choices or parallel executions). Also, as workflows begin to leverage more microservices (e.g., cloud native workflows), the complexity of traditional rollback techniques can become an exacerbated pain point for programmers.